I would store all colours in just one map, given the keys are strings anyway, and have the code understand that non-fractional colours simply have a fractional part of zero. That way you can also look up grayOrNull(1, 0) to get Gray1, but more importantly, code does not have to access two separate maps to find a colour.

To avoid breaking binary changes, we need to keep the old APIs, but deprecate them with DeprecationLevel.HIDDEN

so that means that I should just add new methods (grayOrNull(Int, Int) etc) and also keep the old ones (grayOrNull(Int) etc)?

Yes, for example:

@Deprecated("Use variant with fractional parameter", level = DeprecationLevel.HIDDEN)
public fun grayOrNull(index: Int): Color? = gray.getOrNull(index - 1)

public fun grayOrNull(index: Int, fractional: Int = 0): Color? =
    if (fractional == 0) {
        gray.getOrNull(index - 1)
    } else {
        rawMap["$PALETTE_KEY_PREFIX.Gray$index.$fractional"]
    }

The hidden symbols will still disappear from the dumps, but they will be included in the binary and invisible from code.

Yes — @faogustavo has helpfully listed a legend on how to read the dumps here:

* - marked with @ApiStatus.Experimental.
b - synthetic (as in binary visible). Members with both ACC_SYNTHETIC and ACC_BRIDGE are not included in the dump.
p - protected. Nothing for public because it's the default. private and package-private members are not included.
s - static.
@ - annotation.
e - enum.
f - final.
a - abstract.
c - class. Nothing for interface because it should be the default.

So, you're deprecating with HIDDEN level the existing blueOrNull(Int) — that's why it gets the b added to its existing f (DeprecationLevel.HIDDEN is a clever trick that (ab)uses the concept of a synthetic method in JVM bytecode). This is expected.

Next, you added blueOrNull(Int, Int = 0) where the second parameter has a default value; this is reflected in JVM bytecode as:

1. A f:blueOrNull-6MYuD4A(I,I) with two Int parameters, both non-optional
2. A f:blueOrNull-6MYuD4A$default(...) that is generated by the compiler to implement the default parameter behaviour
   • This is a synthetic static method that you can safely ignore:
     

The weird -6MYuD4A suffixes are also added by the Kotlin Compiler; it's called mangling and you can read more about it here: https://ncorti.com/blog/name-mangling-in-kotlin